home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 007 / tcp_ip.arc / OVERVIEW.DOC < prev    next >
Text File  |  1987-06-12  |  10KB  |  176 lines

  1. This is an overview of the various modules making up the KA9Q Amateur Radio
  2. Internet Protocol package. Each section first describes the protocol that
  3. is supported, followed by a description of the implementation.
  4.  
  5. Subnet layer:
  6.  
  7. A. Standard 10 megabit Ethernet.
  8.  
  9. The driver provided is for the 3-Com 3C500 (IE) controller for the PC.  Tight
  10. (3 instruction) assembler loops are used instead of DMA for copying data in and
  11. out of the controller's buffer; this seems fast enough.  Only the receiver is
  12. interrupt driven; incoming packets are placed on a queue which is then emptied
  13. at a more leisurely pace by the main loop code.  Since Ethernet is so fast,
  14. the transmitter routine busy-waits for completion. The IE controller has only
  15. a single buffer which is shared between receive and transmit. Packets
  16. occasionally get lost under heavy load, especially when several TCP
  17. connections are active at once and/or the TCP receive window sizes are
  18. larger than the MSS values. This is very hard to fix without going to a
  19. newer, more reasonably designed controller.
  20.  
  21. B. Serial Line IP (SLIP) - a very simple technique for sending Internet
  22. Datagrams across ordinary asynchronous lines (e.g., modems). Its only function
  23. is to delimit datagrams with framing characters, which are "byte stuffed"
  24. for transparency. No error checking is provided; the checksums that are part
  25. of IP, TCP and UDP are relied on for this.  SLIP is popular on UNIX
  26. systems that support TCP/IP, so this represented the easiest way to get my
  27. package up and talking with other Internet sites.  It also allows the use of
  28. existing AX.25 TNCs without modifying the latter, although this is should
  29. only be done as a stopgap measure until an HDLC link level driver can be
  30. integrated directly into the package.
  31.  
  32. C. AX.25/KISS TNC - sends and receives IP and ARP datagrams encapsulated in
  33. AX.25 Unnumbered Information (UI) frames. This allows an unlimited number of
  34. simultaneous users on the local radio channel, since there are no
  35. connections at link level.  The special AX.25 Level 3 Protocol ID values of
  36. hex CC (IP) and CD (ARP) are used.
  37.  
  38. This mode of operation requires that the TNC run special "KISS TNC" code.  A
  39. version developed for the TNC-2 by K3MC is provided in this distribution.
  40. The standard TNC-2 ROM must be replaced with a bootstrap ROM and the KISS
  41. TNC code downloaded into the serial port. Note that this style of operation
  42. is NOT compatible with a "stock" TNC carrying SLIP formatted datagrams in
  43. connected mode.
  44.  
  45. D. AX.25/PACCOMM PC-100 interface (NOT YET WORKING) - The PC-100 is an
  46. I/O adapter card for the PC containing a Zilog 8530 Serial Communications
  47. Controller and two AMD 7910 World Chip modems.  The encapsulation method
  48. is identical to (and compatible with) the AX.25/KISS TNC interface driver.
  49.  
  50. E. Address Resolution Protocol (ARP) - used for the automatic mapping of IP
  51. addresses to link or subnet addresses. While originally designed for the
  52. specific task of mapping IP to Ethernet addresses, the protocol is general
  53. enough to be used on any link or subnet that supports a broadcast facility.
  54. ARP is described in ARPA RFC-826.
  55.  
  56. Both Ethernet and AX.25 format addresses are currently supported.  Instead
  57. of discarding a packet when an ARP request is sent, this implementation
  58. holds it on a queue for a limited time, pending a response to the request.
  59.  
  60. Internet layer:
  61.  
  62. F. Internet Protocol (IP) - the universal network-level datagram protocol
  63. of the ARPA Internet. It corresponds roughly to level 3 of the ISO Reference
  64. Model (ISORM). (Actually, IP belongs to the 3B internetwork sublayer if you
  65. follow the amoeboid proliferation of ISO sublayers). Routines are provided
  66. to generate, receive and route (i.e., packet switch) IP datagrams. IP is
  67. specified in ARPA RFC-791 and MIL-STD-1777.
  68.  
  69. IP datagram fragmentation and reassembly is fully implemented. The IP options
  70. Loose Source Routing, Strict Source Routing and Record Route are supported;
  71. Stream ID, Security and Timestamp are ignored. (Few, if any, IP options are
  72. used extensively in the ARPA Internet).  The IP module includes a routing
  73. (packet switching) facility; currently this consists of a table containing a
  74. list of host-specific destinations along with a "default" entry that may be
  75. used when the desired destination is not found in the table. No protocol is
  76. yet provided to actually manage the table; currently it must be done manually,
  77. either locally or remotely.  NB! "Networks" (in the ARPA Class-A/B/C sense)
  78. are not yet understood, in that all entries in the routing table (except for
  79. the default entry) must be host-specific.  This will be fixed in the future
  80. with a "generalized subnetting" scheme that will allow each entry in the table
  81. to have an arbitrary, variable length "subnet mask."
  82.  
  83. G. Internet Control Message Protocol (ICMP) - the error reporting adjunct
  84. to IP. It appears as a pseudo-protocol on top of IP, but is actually
  85. considered to be part of IP. The IP routines automatically generate ICMP
  86. messages whenever an error occurs in the processing of IP datagrams;
  87. incoming ICMP messages are passed up to the originating end-to-end protocol
  88. for appropriate action. ICMP is specified in ARPA RFC-792.
  89.  
  90. This ICMP supports all options except ICMP Timestamps.
  91.  
  92. Host-Host Layer:
  93.  
  94. H. Transmission Control Protocol (TCP) - provides a reliable, sequenced
  95. "virtual circuit" or "connection-oriented" service atop IP on an end-to-end
  96. basis. It corresponds to the Transport layer (level 4) of the OSI model.
  97. Since a single TCP module supports multiple connections through the use of
  98. port numbers, it also provides Session (level 5) functionality without
  99. the need for a distinct layer. (Or it makes the session layer unnecessary,
  100. depending on your point of view). TCP is specified in ARPA RFC-793 and
  101. MIL-STD-1778.
  102.  
  103. The implementation supports an arbitrary number of simultaneous connections,
  104. limited only by memory space for control blocks. An "upcall" mechanism is
  105. available to notify the user of three events: connection state change, receive
  106. data available and transmit buffer space available. The Maximum Segment Size
  107. option is understood and used when it is received, and a global variable is
  108. used for generating MSS in outgoing segments. There is currently no
  109. provision for sending URGent data.  The latest recommendations on "tinygram"
  110. avoidance (Nagle, ARPA RFC-896) are implemented and work quite well.
  111.  
  112. I. User Datagram Protocol (UDP) - provides only a simple, unguaranteed
  113. "datagram" or "connectionless" service, adding only checksums and port
  114. multiplexing to the raw service provided by IP. As an alternative to TCP,
  115. UDP also sits at level 4 (and 5) of the ISORM. UDP is specified in ARPA
  116. RFC-768.
  117.  
  118. The implementation supports the creation of queues on local sockets. An upcall
  119. mechanism similar to that used in TCP notifies the user when datagrams have
  120. arrived.
  121.  
  122. Application Layer:
  123.  
  124. J. File Transfer Protocol (FTP) - for transfer of binary or text files
  125. between hosts. FTP uses two TCP connections - one for exchanging commands and
  126. responses in the form of ASCII strings, and the other for the actual
  127. data transfers. FTP is defined in ARPA RFC-959.
  128.  
  129. FTP is implemented in two parts, a server half and a client half. The server
  130. half supports multiple simultaneous remote users, although at the moment
  131. there is no access control; anyone may access, delete or overwrite any file
  132. on the machine.  The client half is invoked by the "ftp" command.
  133.  
  134. K. Remote login protocol (Telnet) - for logging into remote systems and
  135. negotiating various options, such as remote vs local echoing. Telnet itself
  136. is documented in ARPA RFC-854, with the many options defined in other
  137. RFCs.
  138.  
  139. The client half supports the ECHO and TRANSMIT-BINARY options; it is invoked
  140. by the "telnet" command. A telnet "server" has been written, but since MS-DOS
  141. isn't a timesharing system it is used for keyboard-to-keyboard conversations
  142. instead. An incoming connect request to the local Telnet port creates a local
  143. Telnet session and notifies the local user. He may then select the new session
  144. and carry out a conversation with the remote initiator.
  145.  
  146. L. Simple Mail Transfer Protocol (SMTP) - as the name implies, is used for the
  147. transfer of electronic mail between hosts. SMTP commands and responses are
  148. strings of ASCII characters resembling those used by FTP. SMTP uses a
  149. single TCP connection for both control and the actual mail messages.
  150. SMTP is described in ARPA RFC-821; headers in mail messages are described
  151. in RFC-822.
  152.  
  153. A simple version server (receiver) is implemented; it accepts mail from a
  154. remote sender and appends it to a mailbox. Mail forwarding, which accounts for
  155. much of the complexity in other mail servers, is not implemented. A mail
  156. client ("user agent") for composing and sending messages developed by Bdale 
  157. Garbee, N3EUA, is included.  It is called 'BM', and is documented elsewhere.
  158.  
  159. M. Session control - the user may manage several simultaneous Telnet and
  160. FTP client invocations. Only one client session is "active" at any one time,
  161. but the user may quickly switch between them. Terminal output arriving for
  162. an inactive session is held until that session is again made active.  (Note
  163. that this is in addition to the multiple server sessions which go on
  164. automatically "in the background", i.e., without operator intervention).
  165.  
  166. The Internet package has been tested with and works under DoubleDos 3.1U
  167. by SoftLogic Solutions, allowing the system to be simultaneously "on the net"
  168. while executing conventional MS-DOS commands.  The net program uses the special
  169. DoubleDos function call 0EEH to relinquish the processor when it isn't needed;
  170. this speeds up the task running in the other partition.  This function is a
  171. "no-op" when DoubleDos isn't active.
  172.  
  173. Phil Karn, KA9Q
  174. 4 Nov 1986
  175.  
  176. updated 870525 by Bdale, N3EUA